Intro

Grundlagen

  • Es gibt zwei grundlegende Arten, ein Netz zu bauen:
    • mit Ressourcenreservierung: Leitungsvermittlung -> gut bei konstanter Bandbreitennutzung
    • ohne Ressourcenreservierung: Paketvermittlung -> gut bei variabler Bandbreitennutzung
  • Komplexe Struktur des Internets -> ISPs verbinden sich untereinander
    • grob hierarchisch

Verzögerung, Paketverlust und Durchsatz

Paketgröße:

$$ L := 1\cdot[\text{bit}] $$

Bandbreite:

$$ R := \frac{L}{t} $$

Verzögerungen:

$$ \begin{array}{} \text{"Verarbeitungsverzögerung"} & := & D_V \\ \text{"Wartezeit im Routern"} & := & D_W \\ \text{"Übertragungsverzögerung"} & := & D_Ü \\ \text{"Ausbreitungsverzögerung"} & := & D_A \\ D_\text{gesamt} & = & D_V + D_W + D_Ü + D_A \end{array} $$

Schichtenmodell

TCP/IP:

Schicht Protokoll Dateneinheit von Protokoll Adressierung
Anwendung (application) Http, SMTP, SSH,... Nachricht n/a
Transport (transport) TCP/UDP Segment Ports
Netzwerk (network) IP Datagramm IP Adressen
Sicherung (link) Ethernet, WLan Rahmen Mac Adressen
bitübertragung (physical) 10 base t, 802.11 Bits n/a

ISO/OSI: -> Teilt die Anwendungsschicht in zwei weiteren in sich selbst auf

TCP/IP ISO/OSI
Anwen- Anwendungsschicht
dungs- Darstellungsschicht
schicht Kommunikationsteuerungsschicht
... ...

Kapselung: Kapselung

Anwendungsschicht

  • benötigt Port-Nummer oder IP-Adresse
  • teilt sich in zwei Kategorien ein
    • Client-Server
    • P2P
  • Protokolle der Anwendungsschicht definieren:
    • Art der Nachricht (Request/Response)
    • Syntax (ähnlich zu Programmiersprachen)
    • Semantik (Bedeutung der Nachricht)
    • Regeln für das Senden und Empfangen
    • Auslösen von Aktionen
    • Verhalten im Fehlerfall

Das Web

Das Web

HTTP

Request-Nachrichtenformat

<Methode> <Ressource> <HTTP/1.1> \r\n
<Schlüßelwort>: <value>\r\n
...
\r\n
%%bash
http GET myip.is -v

GET / HTTP/1.1
User-Agent: HTTPie/2.4.0
Accept-Encoding: gzip, deflate
Accept: application/json, */*;q=0.5
Connection: keep-alive
Content-Type: application/json
Host: myip.is



HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Tue, 22 Apr 2025 15:43:30 GMT
Content-Type: text/html
Content-Length: 162
Connection: keep-alive
Location: https://myip.is/

<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>

Request Methoden

Methode Beschreibung
GET Ressource Anfragen
HEAD nur Header Anfragen
POST Daten zum Server schicken
PUT Daten auf Server ablegen
DELETE Objekte auf Server löschen
CONNECT Anfrage auf TCP/IP tunnel
OPTION Optionen oder Servereigenschaften abfragen
TRACE Gibt gesendete Nachricht zurück

Status Codes

Ziffer Beschreibung Beispiel
1xx Informational: Request ist angekommen und wird weiter bearbeitet 101 Switching Protocols
2xx Successful: Angekommener Request wurde verstanden und erfolgreich beantwortet 200 OK
3xx Redirection: Angekommener Request muss anders angefragt werden 301 Moved Permanently
4xx Client Error: Falsche Syntax oder Request kann nicht beantwortet werden 404 Not found
5xx Server Error: Gültiger Request scheitert an Server-Problemen 500 Internal Server Error

HTTP-Cookies

https://youtu.be/4rQpz9kNpTE?si=ZDqTFZY1eo9fiWt9&t=4079

Cookies werden benötigt, um Zustände zu halten. session.png Vom Server wird ein Cookie an den Client mit Set-cookie geschickt. Der Client sendet nun den Cookie mit Cookie bei jeder folgenden Request mit, damit der Server den Client wieder identifizieren kann. -> die Cookies werden jeweils vom Client (Cookie Jar) und Server verwaltet.

Klassifizierung von Cookies

  • Session Cookies: werden daher typischerweise bei Schließung des Browsers gelöscht
  • Persistent Cookies: Cookies mit Ablaufdatum
  • First-party Cookies: Cookies vom Server der aktuell besuchten Seite
  • Third-party Cookies: Cookies von anderen Servern (z.B. Ads)

Attribute

  • Nutzungsdauer (Machen aus Session Cookie einen Persistent Cookie) Mit:
    • Expires: Ab einen bestimmten Datum
    • Max-Age: Nach einer bestimmten Zeit in Sekunden
  • Übertragungsart:
    • Secure: nur über HTTPs
    • HttpOnly: nur HTTP Protokoll darf verwenden (Verbietet JavaSkript den Zugriff auf Cookies)
  • Domain: Cookies werden nur an diese Domain mit deren Subdomains geschickt
  • Path: Cookies werden nur an diesem Pfad und darunter liegende Pfade versendet
  • Samesite: regelt, das Senden des Cookies auf Seiten die diesen Cookie nicht gesetzt haben

Beispiele

Cookies werden bei Firefox in einer Datenbank gespeichert (Pfad unter Windows: %appdata%\Mozilla\Firefox\Profiles\xxxxxxxx.default bzw. Linux ~/.mozilla/firefox/xxxxxxxx.default.) Unter den Developer Tools könne Cookies eingesehen werden: image.png Es gilt dabei, dass das erste Wertepaar vom Server definiert ist, und dann darauf die Attribute des Cookies folgen.

Beispiel Moodle Login:

POST /login/index.php HTTP/1.1
Host: moodle.hs-augsburg.de
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:137.0) Gecko/20100101 Firefox/137.0
Accept-Language: en-US,en;q=0.5
Origin: https://moodle.hs-augsburg.de
Connection: keep-alive
Referer: https://moodle.hs-augsburg.de/login/index.php
[...]
Cookie: PHPSESSID=xxxxxx; SimpleSAMLAuthToken=xxxxxx10a91becc103958b6; ezproxy=QF63iJuSOvpT6c6; ezproxyl=QF63iJuSOvpT6c6; ezproxyn=QF63iJuSOvpT6c6; MoodleSession=xxxxxx

Attribute werden nicht mit versendet, nur die Cookie mit deren Werten

Darauf folgende Response:

HTTP/1.1 303 See Other
date: Mon, 21 Apr 2025 15:16:31 GMT
expires: Thu, 19 Nov 1981 08:52:00 GMT
content-language: de
location: https://moodle.hs-augsburg.de/login/index.php?testsession=32223
[...]
set-cookie: MoodleSession=xxxxxx; path=/; secure

HTTP-Cache

https://youtu.be/4rQpz9kNpTE?si=-5zBhJOksw_20IGs&t=5047

Jeder Browser cachet Inhalte lokal

Es gibt auch Server im Netz, die Inhalte cachen

  • werden teils Autoconfiguriert
  • Client sendet dann HTTP-Request an den Cache
  • wenn Objekt nicht im Cache, fragt der Cache den Server an
  • Vorteil, ein Cache für mehrere Clients
    • kürzere Antwortzeit
    • weniger Traffic auf der Zugangsleitung
    • Entlastung des Webservers
  • HTTP-Header können Server Caching unterdrücken oder steuern
    • Großkonzerne verzichten gerne auch auf Caches, um personalisierten Content zu senden
  • Bietet auch Security Features (Kontrolle von Traffic)

Bedingtes GET

In dem Header des HTTP Request wird das mit dem Schlüsselwort If-modified-since: <Zeitpunkt> angefragt, ob sich das gecachten Objekt geändert hat. Der Server antwortet dann mit:

  • 304 Not Modified
  • 200 Ok + dem aktuellen Objekt im Body

HTTP/2

https://youtu.be/_vr80I-o1gI?si=US_O8LbjU552OP3X&t=579

HTTP/1.1 war auf verschiedener Hinsicht ineffizient

  • Header konnten ziemlich groß werden, da sie ASCII-codiert und unkomprimiert waren
  • häufige Wiederholung im Header (Browser-Info wird immer wieder erneut gesendet)
  • keine Priorisierung der Ressourcen
  • für Seite benötigte - aber noch nicht angefragte Ressourcen - konnten nicht schon direkt vom Server gepusht werden

Andere Protokolle wie SPDY haben sich dann durchgesetzt. HTTP/2 vereinheitlichte diese, ersetzt jedoch nicht HTTP/1.1 (HTTP/2 ist nicht abwärtskompatibel zu 1.1).

HTTP/3 ist bereits spezifiziert (entspricht HTTP/2 über das QUIC Transportprotokoll)

Konzepte:

  • gesamte Kommunikation läuft über eine einzige TCP-Verbindung

  • Stream

    • bidirektionaler Datenfluss, der ein oder mehrere Nachrichten transportiert

    • besteht aus eindeutiger Kennung und einer optionalen Priorität

      • Gewichtung zwischen 1 und 256

      • keine Gewichtung bedeutet abhängig vom "Root-Stream"

        Beispiel: Zuerst D, dann E und C im gleichen Verhältnis, dann A drei mal so viel/schnell wie B

        image.png

  • Frames
    • enthält Header, der die Stream-Zugehörigkeit ausdrückt
    • sowie Body, welcher Daten, HTTP-Header oder Payload beinhaltet

Eine TCP-Verbindung Veranschaulichung: -> Header und Daten werden in mehreren Frames unterteilt image.png

-> Dies ermöglicht einen nicht sequenziellen Datenverkehr (Multiplexen von Requests und Responses) image.png

Server Push

Noch nicht angefragte Ressourcen, die jedoch später auf jeden Fall noch angefragt werden, werden gleich gepusht.

Kann nur seine eigenen Ressourcen (same origin) pushen image.png

Wird jedoch nicht mehr von Chrome unterstützt.

Header Compression

  • Header-Felder werden mit Huffman Code komprimiert
  • Bereits gesendete Felder, werden nicht nochmals verschickt sondern sind implizit gesetzt image.png

Head-of-Line Blocking

Ein verloren gegangenes TCP-Packet blockiert die darauffolgenden Streams, da bei HTTP/2 nur eine TCP-Verbindung genutzt wird (Unter Umständen wäre hier sogar HTTP/1.1 schneller, da meherere TCP-Verbindungen)

HTTP/3 löst dieses Problem

DNS

https://youtu.be/_vr80I-o1gI?si=qex-jEG7PDbXGll7&t=2827

DNS funktioniert ähnlich wie eine Telefonauskunft. Der Benutzer kennt die Domain (wie Name im Telefonbuch) und sendet eine Anfrage in das Internet, um dessen IP-Adresse zu bekommen.

  • Ein Name kann auf mehrere IP-Adressen verweisen für z.B. Lastverteilung
  • mehrere Namen können auf eine IP-Adresse verweisen, z.B. Alias-Name
  • Adressen können sich ändern, sich flüchtiger als Domains

Hierarchischer Namensraum: image.png

  • jeder Knoten kann bis zu 63 Zeichen lang sein

DNS-Server unterscheiden sich zwischen:

  • root nameserver
  • Top-Level-Domain Server
  • Autoritative DNS-Server
    • Unterste Ebene der DNS-Hierarchie
    • Typischerweise durch die Organisation gestellt, denen die Namen und IP-Adressen zugewiesen sind oder ISP

Rekursiver (lokaler) DNS-Server

  • gehört nicht zur Hierarchie der DNS-Server
  • dient unter anderem auch zum Cachen
  • öffentlich betriebene rekursive DNS-Server heißen Open Resolver

Namensauflösung

Iterativ

image.png Rekursiver DNS-Server arbeitet sich vom Root bis zum autoritativen DNS-Server durch.

Rekursiv

image.png Die Anfrage wird bis zum autoritativen DNS-Server weitergeleitet. -> höhere Last durch Hierarchie (Verbindung muss vom Root gehalten werden) -> werden haubtsächlich Lokal durchgeführt

Resource Records (RR)

 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                                               |
/                                               /
/                     NAME                      /
|                                               |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                     TYPE                      |
|              ## Art des RR ##                 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                     CLASS                     |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                      TTL                      |
|              ## Time to live ##               |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                   RDLENGTH                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/                     RDATA                     /
/               ## Daten des RR ##              /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

RR Typen

  • A: RDATA enthält IPv4 Adresse
  • AAAA: RDATA enthält IPv6 Adresse
  • NS: RDATA enthält Namen des DNS-Servers der angefragten Domäne (Nameserver)
  • MX: RDATA enthält Namen des Mail-Servers der angefragten Domäne (Mail Exchange)
  • CNAME: RDATA enthält den echten Namen der angefragten (alias) Domäne (Canonical Name)
  • [...]

DNS-Nachricht

 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                       ID                      |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR|   Opcode  |AA|TC|RD|RA|    Z   |   RCODE   |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    QDCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ANCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    NSCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
|                    ARCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    QUESTION                   |
//                                             //
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ANSWER                     |
//                                             //
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    AUTHORITY                  |
//                                             //
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ADDITIONAL                 |
//                                             //
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  • QR-Flag bestimmt Request oder Response
  • AA-Flag gibt an, ob es sich um eine autoritative Antwort handelte.
  • RD-Flag fragt eine rekursive Bearbeitung ab
  • RA-Flag Recursion Available
  • ID weißt die Response einem Request zu
  • *COUNT gibt an, wie viele RR in den unteren Sektionen sind
  • RCODE Response Code

DNS-Protokoll

  • läuft über UDP Port 53 (auch über TCP spezifiziert)
  • TLS und DNS über HTTPs sind ebenfalls spezifiziert

SMTP

https://youtu.be/9Rwoe3NoOuY?si=Fi6LQ0Cd92XoQDQq&t=1902 image.png

Vom Sender zum eigenen Mailserver.

Vom eigenen Mailserver zum empfangenden Mailserver.

  • Mail Objects
    • Bestehend aus einem „Umschlag“ (envelope) und dem Mail-Inhalt
    • Der Mail-Umschlag ist eine Reihe von Kommandos
    • Der Mail-Inhalt besteht erneut aus einem Header und der Mail selbst (Body)
  • Mail Transfer Agents (MTAs)
    • SMTP-Clients und SMTP-Server
  • Mail User Agents (MUAs or UAs)
    • Quelle oder ultimatives Ziel einer Mail
  • Mailbox und Adresse
    • Die Adresse ist ein String, der angibt, an wen oder von wem die E-Mail kommt
    • Mails können dabei in einer Mailbox zur Abholung gespeichert werden
    • Die Adress/Mailbox Namenskonvention ist dabei "local-part@domain"

Beispiel

Wikipedia

  • Alle Kommandos/Antworten enden mit <CRLF>
  • s: steht für Server und c: für Client
smtp
s: 220 smtp.hs-augsburg.de ESMTP Postfix       //Server stellt sich vor
c: EHLO mail.example.com                       //Sitzung wird gestartet
s: 250-smtp.hs-augsburg.de
s: 250-PIPELINING
s: 250-AUTH PLAIN LOGIN
…                                              //Nach Eröffnung der Sitzung, 
s: 250 SMTPUTF8                                //wird mitgeteilt, welche Erweiterungen der Server kann, etc. 
c: MAIL FROM: <postmaster@example.com>         //Fehler werden an diese E-Mail geschickte 
s: 250 2.1.0 Ok                                //(nicht zwangsläufig Absender)
c: RCPT TO: <rolf.winter@hs-augsburg.de>
s: 250 2.1.5 Ok
c: DATA
s: 354 End data with <CR><LF>.<CR><LF>         //Ende des Envelope, Mail startet jetzt
C: From: "Postmaster" <postmaster@example.com> //start des Header der E-Mail
C: To: "Rolf Winter" <rolf.winter@hs-augsburg.de>
C: Cc: theboss@example.com
C: Date: Tue, 15 Jan 2008 16:02:43 -0500
C: Subject: Bewertung Volesung
C:                                             //start des Body der E-Mail
c: Tolle Vorlesung
c: .
s: 250 2.0.0 Ok: queued as 4317320361
c: QUIT
s: 221 2.0.0 Bye

MIME

Multipurpose Internet Mail Extensions Wird verwendet um jegliche Anhänge zu versenden

smtp
[...]
354 End data with <CR><LF>.<CR><LF>
From: asdf@example.com
To: lukas.mensch@tha.de
Subject: Subject goes here.
Date: Tue, 22 Apr 2025 16:44:26 +0200
MIME-Version: 1.0
Content-Type: Multipart/Mixed;
    boundary="Mark=_2025422144420323eNHXEyZ"
X-mailer: NetScanTools® Pro 11 SMTP Email Generator
                                                                             //Start des E-Mail Bodys
This is a multi-part message in MIME format.

--Mark=_2025422144420323eNHXEyZ
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: Quoted-Printable

Your message goes here.                                                      //Textnachricht hier
--Mark=_2025422144420323eNHXEyZ                                              //Versenden der Anhänge
Content-Type: Application/Octet-stream; name="netscantools_pro_report_banner.gif"; type=Unknown
Content-Transfer-Encoding: BASE64

R0lGODlhLwJkAPcAAAAAAAYGBQsLChgZFxERDygqJTg6NDI0LCEjHT5BOERIPElLR1RXTV5iVWNo //BASE64 kodierte Daten
[...]
FrShLWxAAAA7

--Mark=_2025422144420323eNHXEyZ
Content-Type: Application/Octet-stream; name="dctnry.txt"; type=Unknown
Content-Transfer-Encoding: BASE64

cHVibGljDQpwcml2YXRlDQpwYXNzd29yZA0KUGFzc3dvcmQNCnBhc3N3b3JkMQ0KMA0KMw0KNA0K //BASE64 kodierte Daten
[...]
Ym5tDQp=

--Mark=_2025422144420323eNHXEyZ--

.
250 2.0.0 Ok: queued as 4ZhlPR58cWz6D
QUIT

MIME-Types Liste

Email-Zugriff

https://youtu.be/9Rwoe3NoOuY?si=THLVwXYef1KCnxYs&t=2956

  • POP3 (Post Office Protocol v3)
    • Nach dem Download wird die E-Mail auf dem Server gelöscht
  • Internet Message Access Protocol (IMAP)
    • Mails werden so wie Dateien auf dem Computer gemanagt
    • Zustand kann gehalten werden
    • Großer Funktionsumfang

FTP

https://youtu.be/9Rwoe3NoOuY?si=Gsy-tFP4OaYq3xLw&t=3220 image.png

Dateiübertragungsdienst, um auf entfernte Dateisysteme zuzugreifen

Es gibt zwei Kanäle:

  • Kontrollverbindung, um Datenverzeichnis auf Server zu verwalten (auf Port 21(TCP))
  • Datenverbindung, um Daten zu übertragen (Port wird vom Server mitgeteilt(TCP))
  • Kontrolle nennt sich "out-of-band" (Bei Upload einer Datei muss nicht zur Verwaltung auf Ende des Uploads gewartet werden)

Transportschicht

https://youtu.be/9Rwoe3NoOuY?si=ni31zdjGqqgvyTJn&t=3690

Sender teilt Daten der Anwendung in Segmente auf, welche vom Empfänger wieder zusammengefügt werden.

Ist in der Regel im Betriebssystem implementiert

Sockets

Handle, um Daten über ein Netzwerk zu schicken

  • verhält sich fast wie ein file descriptor
  • wird identifiziert durch IP-Adresse und Port-Nummer
  • Details sind abhängig von der Art des Transportprotokolls (TCP oder UDP)
import socket

# create a socket object 
s = socket.socket()
print ("Socket successfully created")

# reserve a port on your computer 
port = 12345

# next bind to the port 
# we have not typed any ip in the ip field 
# instead we have inputted an empty string 
# this makes the server listen to requests 
# coming from other computers on the network 
s.bind(('', port))
print ("socket binded to %s" %(port)) 

# put the socket into listening mode 
s.listen(5)
print ("socket is listening")

# Establish connection with client. 
c, addr = s.accept()
print ('Got connection from', addr )

# send a thank you message to the client. encoding to send byte type. 
c.send('Thank you for connecting'.encode()) 

# Close the connection with the client 
c.close()

Socket successfully created
socket binded to 12345
socket is listening
Got connection from ('127.0.0.1', 50478)

%%bash
# $ telnet localhost 12345

# Trying 127.0.0.1...
# Connected to localhost.
# Escape character is '^]'.
# Thank you for connectingConnection closed by foreign host.

UDP wird durch einen 2-Tupel adressiert
-> Empfänger IP-Adresse und Empfänger Port-Nummer
-> Ein Socket für alle Verbindungen

TCP wird durch einen 4-Tupel adressiert
-> Sender/Empfänger IP-Adresse und Sender/Empfänger Port-Nummer
-> Für jede Verbindung jeweils einen Socket (da durch Warten auf Antwort unter einer Verbindung Überlastung bei anderen Clients entsteht)

Multiplexen/Demultiplexen

https://youtu.be/9Rwoe3NoOuY?si=mOlOrzP6gp_mRP-Z&t=4064

  • Demultiplexen beim Empfänger
    -> Paket wird dem richtigen Prozess übergeben
  • Multiplexen beim Sender
    -> vom Prozess übergebenen Paket wird mit einem Port versehen, welcher für das Demux. benötigt wird

16-bit große Portnummern werden unterteilt in:

  • Well-Known (System) Ports: 0-1023
    • für essenzielle Anwendungen, wie HTTPs oder SSH
  • Registered (User) Ports: 1024-49151
    • für normale Anwendungen
  • Dynamic Ports: 49152-65535
    • werden zufällig vom Client benutzt

UDP

https://youtu.be/9Rwoe3NoOuY?si=6V_4GriKREanH9ec&t=4186

Das User Datagram Protocol ist nur ein minimale Erweiterung des Dienstes von IP (best-effort)

  • fügt Ports hinzu
  • keine Garantie auf Richtigkeit der versendeten/empfangen Pakete
    • jedoch können Bitfehler erkannt werden
  • es muss keine Verbindung zuvor aufgebaut werden (verbindungslos)
  • Vorteile
    • keine Verzögerung durch Verbindungsaufbau
    • wenig Overhead
    • Einfach
    • keine Überlastungskontrolle
  • Einsatzgebiete
    • Live Multimedia
    • DNS
    • Basis für andere Transportprotokolle in der Anwendungsschicht (QUIC, WireGuard,...)

UDP-Header

0       7 8     15 16    23 24    31
+--------+--------+--------+--------+
|     Source      |   Destination   |
|      Port       |      Port       |
+--------+--------+--------+--------+
|     Length      |    Checksum     |
| of the Datagram |                 |
+--------+--------+--------+--------+
|
|            data octets ...
+---------------- ...

Prüfsumme

Algorithmus

  1. Paket wird als Folge von 16-bit Werten betrachtet
  2. Bei der Berechnung (senderseitig) wird das Prüfsummenfeld auf 0 gesetzt
  3. Die Einerkomplementsumme der 16-bit Werte wird gebildet und invertiert (Negation) in das Prüfsummenfeld eingetragen
  4. Bei der Überprüfung der Summe (empfängerseitig) wird die Summe wie oben berechnet, nur, dass das Prüfsummenfeld nicht auf 0 gesetzt wird. In der so errechneten Prüfsumme müssen alle Bits gesetzt sein (-0 in Einerkomplementarithmetik) image.png

Pseudo-Header

Für die Erzeugung der UDP-Prüfsumme werden Teile dieses IP-Headers in einen sogenannten „Pseudo-Header“ übernommen.

TCP

https://youtu.be/9Rwoe3NoOuY?si=QBsqHarUxUwYhePL&t=5027

Benötigte Informationen für einen zuverlässigen Transportdienst

  • Bitfehlererkennung
  • Empfängerfeedback
  • Timer
  • Sequenznummern
  • SYN (Synchronize)
  • SYN-ACK (Synchronize-Acknowledge)
  • ACK (Acknowledge)